home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / ietf / urn / urn-archives / urn-ietf.archive.9701 / 000043_owner-urn-ietf _Fri Jan 31 11:56:47 1997.msg < prev    next >
Internet Message Format  |  1997-02-19  |  4KB
  1. Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id LAA03192 for urn-ietf-out; Fri, 31 Jan 1997 11:56:47 -0500
  2. Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id LAA03187 for <urn-ietf@services.bunyip.com>; Fri, 31 Jan 1997 11:56:39 -0500
  3. Received: from sdgmail.ncsa.uiuc.edu by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b)
  4.         id AA25934  (mail destined for urn-ietf@services.bunyip.com); Fri, 31 Jan 97 11:56:37 -0500
  5. Received: from void.ncsa.uiuc.edu (void [141.142.103.20]) by ncsa.uiuc.edu (8.8.5/8.8.5) with ESMTP id KAA15830; Fri, 31 Jan 1997 10:56:23 -0600 (CST)
  6. From: Daniel LaLiberte <liberte@ncsa.uiuc.edu>
  7. Received: (from liberte@localhost) by void.ncsa.uiuc.edu (8.8.2/8.8.2) id KAA03953; Fri, 31 Jan 1997 10:56:39 -0600 (CST)
  8. Date: Fri, 31 Jan 1997 10:56:39 -0600 (CST)
  9. Message-Id: <199701311656.KAA03953@void.ncsa.uiuc.edu>
  10. To: "Ron Daniel Jr." <rdaniel@lanl.gov>
  11. Cc: "omar syed" <osyed@lerc.nasa.gov>, "URL mailing list" <ietf-url@imc.org>,
  12.         <urn-ietf@bunyip.com>
  13. Subject: Re: [URN] Re: Relative URLs and URNs
  14. In-Reply-To: <199701310644.XAA03311@acl.lanl.gov>
  15. References: <199701310644.XAA03311@acl.lanl.gov>
  16. Sender: owner-urn-ietf@services.bunyip.com
  17. Precedence: bulk
  18. Reply-To: Daniel LaLiberte <liberte@ncsa.uiuc.edu>
  19. Errors-To: "owner-urn-ietf@bunyip.com
  20.  > Thus spoke Omar Syed:
  21.  > > 2. clients must treat" <NSS> as an opaque string (i.e. do not interperet)
  22.  
  23.  
  24. Ron Daniel, Jr. writes:
  25.  > I think assumption 2 is in error. Clients that know the structure of
  26.  > a name in a particular namespace are likely to manipulate it.
  27.  
  28. I agree.  Clients, of course, can do whatever they want (whatever they
  29. can get away with) anyway, but they have to be able to interpret the
  30. structure of an identifier in order to do as much processing of it on
  31. their own as they can.  Forcing clients (if that were possible) to
  32. always consult a remote server to process the whole identifier is a
  33. sure way to make the system unscalable.
  34.  
  35. Ron Daniel, Jr. writes:
  36.  > This is the sort of problem I am running into now in our tests, where
  37.  > we have a bunch of HTML pages we are retroactively assigning URNs to.
  38.  > Since those pages have lots of relative links in them, we can either:
  39.  >   1) Make sure our new URNs reflect the same filesystem arrangement
  40.  >      as the pages do.
  41.  >   2) Modify the pages to make all the references absolute.
  42.  > Alternative 1 certainly is unattractive, since a major point of URNs is
  43.  > to provide independence from the filesystem organization du jour.
  44.  
  45. First, identifiers (relative or not) may *reflect* a filesystem
  46. structure, but it is up to the server whether to look up an identifier
  47. in a filesystem, database, or pass it to a CGI program, for
  48. example.  So it is incorrect to assume filesystems specifically.
  49.  
  50. But going beyond that, the identier may reflect a hierarchical
  51. structure (filesystem or not) and if you want that structure to be
  52. persistent, you have to arrange that old identifiers are redirected
  53. to the new identifiers, and the old identifiers are not reused for
  54. other purposes.
  55.  
  56. Redirecting is supported by NCSA httpd, and I assume many other servers.
  57. Instead of sending a redirection back to the client, the server could
  58. handle it itself, especially if the new place is within the same server.
  59.  
  60. --
  61. Daniel LaLiberte (liberte@ncsa.uiuc.edu)
  62. National Center for Supercomputing Applications
  63. http://union.ncsa.uiuc.edu/~liberte/